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REMARKS 

Applicants have thoroughly considered the Examiner's remarks in the final Office action 
dated February 5, 2009. This Amendment E amends claims 1,11, and 12, and cancels claim 10. 
Claims 1, 3-9, and 1 1-33 are thus presented in the application for further examination. No new 
matter has been added. Reconsideration of the application as amended and in view of the 
following remarks is respectfully requested. 

No New Issues 

Applicants have incorporated the subject matter of claim 10 into claim 1 and canceled 
claim 10. Claim 10 depended from claim 1. Thus, the subject matter of claim 10 has been 
previously considered, and this amendment presents no new issues. Therefore, the Examiner 
should enter the amendment and consider the following remarks. 

Claim Rejections Under 35 U.S.C. $ 102 

Claims 1 and 3-33 stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent Publication No. 2004/0066414 by Czerwinski et al. (hereinafter Czerwinski). Applicants 
submit that the cited reference fails to teach each and every element of the claims of the present 
application. 

At page 6 of the Office action, the Examiner asserts that Czerwinski teaches providing a 
user interface option menu for revealing the current tile status to a system user because at 
paragraph 38, Czerwinski discloses "additional text and graphics can be associated with tiles". 
The referenced portion of paragraph 38 states: 

"The group control tile 128 can include additional text and/or graphics that 
identify the group control tile 128 and/or the control tiles 1 18,120 in the control 
tile group 126. For example, the group control tile 128 can include a textual 
and/or graphical identifier for the group. Additionally, the group control tile 128 
can include an indication of the number of control tiles that are part of the 
particular group. Further, to identify which control tiles are included with the 
group, the group 126 can be displayed with a continuous border around the each 
of the grouped control tiles 118, 120. Additionally, the group 126 can displayed in 
a color schema to distinguish particular groups from the taskbar 1 14 or other 
groups. Additional techniques may be also be applied to identify particular groups, 
including differing display fonts, variable thickness borders, and/or adjusting the 
dimensions of the control tiles 118, 120." 
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The cited portion of Czerwinski thus states that "the group control tile 128 can include additional 
text and/or graphics that identify the group control tile 128 and/or the control tiles 1 18,120 in the 
control tile group." Czerwinski does not teach that the status of a tile as defined by the present 
claims is displayed to a user. 

In contrast, claim 1 recites that "the current status includes at least one of the group 
comprising: hidden, visible, newly installed, uninstalled, and banned," and " providing a user 
interface option menu for revealing the current tile status to a system user". Applicants submit 
that the labeling aspect of Czerwinski is inconsistent with revealing a current tile status to a user 
as claimed. Czerwinski makes no provisions for labeling or displaying a status of a tile that is 
banned, hidden, or uninstalled. In the implementation of Czerwinski, tiles cannot have such a 
status, and there is no need to draw a distinction between a newly installed or visible tile- 
Therefore, Czerwinski fails to teach these aspects of the claims, and claim 1 is allowable over the 
cited art. 

In general, Czerwinski is directed to a graphical user interface having a desktop section 
and a taskbar section. Windows in the desktop have a corresponding tile in the taskbar. Tiles in 
the taskbar may be grouped by the user such that the user can efficiently (i.e., quickly) minimize 
or restore a group of windows (see Czerwinski at Abstract, paragraph 21, and paragraphs 36-39). 
The user can add or remove a tile from a group by drag and drop functionality, via a series of 
menus or other controls, through gestures used to select and designate control tiles for grouping, 
by drawing a circle around each control tile to be grouped, and/or by utilizing selection tools 
such as geometric shapes that group any control tiles encompassed, partially or completely by 
the selection tool (see Czerwinski at paragraph 37). Czerwinski teaches that all grouping or 
ungrouping requests are initiated by the user. Czerwinski thus fails to teach determining the 
identity of a requestor (i.e., determining an originator of a request), selecting a rule set based on 
the determined identity (i.e., originator), and a second rules set such as the application rules set. 
Czerwinski further fails to teach determining a status of a selected tile (i.e., hidden, visible, 
newly installed, uninstalled, or banned). 

At page 14, of the Office action, the Examiner asserts that Czerwinski at paragraphs 38-40 
teaches applying different rule sets based on the identity of a manipulation requestor. The 
Examiner asserts that in paragraph 40, "rule sets effects the final presentation of the taskbar and 
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its grouping of elements, such that there are different means of presenting information to the 
used based on determined parameters (user or system)." (sic). Paragraph 40 discloses that the 
operating system may automatically collapse a group when the available display space on a 
taskbar is exceeded. The group is collapsed in the same way and displayed in the same way 
regardless of whether the user requests that the group be collapsed, or the operating system 
automatically collapses the group. Thus, the same set of display rules is used, regardless of the 
identity of the manipulation requestor, and Czerwinski fails to teach any difference in the applied 
rules based on the identity of the manipulation requestor. 

At pages 14 and 15 of the Office action, the Examiner also asserts that paragraph 39 
teaches, "... other rule sets that are called predefined layouts which are rules defined to effect 
how the presentation of groupings and single elements are displayed to the user to be interacted 
with inside of the taskbar." Czerwinski only teaches the user requesting the predefined layouts 
for the tiles in the group. Czerwinski docs not determine the originator of a request (i.e., user or 
operating system) because it assumes that only a user can request that the tiles be arranged on the 
desktop. Again, Czerwinski fails to teach any difference in the applied rules based on the 
identity of the manipulation requestor. 

In contrast to the cited art, aspects of the present claims are directed to an application 
implementing a sidebar that treats requests to manipulate the sidebar originating from an 
application differently than requests to manipulate the sidebar originating from a user. That is, 
the requests are treated differently based on the source of the request (i.e., the identity of the 
requestor or the originator of the request). This allows applications (i.e., applications other than 
the framework implementing the sidebar) to add tiles to the sidebar while providing superseding 
user control (i.e., manipulation) of the sidebar and its tiles. For example, if a user adds a tile to 
the sidebar via a tile configuration user interface program (e.g., a sidebar interaction interface), 
the tile appears at or near the top of the visible sidebar. However, if a program attempts to add a 
tile to the sidebar, the tile appears at the bottom of the sidebar, or may be forced into an overflow 
area. Additionally, if the tile that a program is attempting to add has been previously removed 
from the sidebar by the user (e.g., the status of the tile is determined to be "banned"), the tile 
cannot be added to the sidebar (or the overflow) without user intervention (see, for example, 
Application at paragraph [0069]-[0074]). For example, a newly installed application program 
may originate an application request to add a tile of the newly installed application program to 
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the sidebar. However, the application request may be immediately superseded by a user request 
when an application request triggers a notification form the tile configuration user interface 
program asking for user input or denial of the request (see Application at paragraphs [0083]- 
[0084]). Therefore, the sidebar application of the present claims recognizes two distinct 
originators of requests (i.e., users and applications) and applies rules as a function of the 
originator. 

To this end, claim 1 recites, "... in response to receiving said request, 
determining the originator of said received request; selecting an appropriate manipulation 
rule set from a plurality of rule sets comprising a user manipulation rule set and an 
application manipulation rule set, said selecting based on the determined originator of the 
request , wherein a user manipulation rule set is selected if the determined originator of the 
request is a system user, and an application manipulation rule set is selected if the 
determined originator of the request is an application, wherein said application is associated 
with the selected tile and is an application program other than a tile configuration user interface 
program...." Claim 13 recites, "...one or more application manipulation rules defining an 
appropriate disposition of the selected tile based on the indicated current status of the 
selected tile and the content of the request, wherein said application manipulation rules 
and not said user manipulation rules are used when the manipulation request originates 
from the application, wherein said application is associated with the selected tile and is an 
application program other than a tile configuration user interface program. ..." Claims 24, 30 
and 32 reinforce that the source of a request affects the processing of that request by identifying 
three specific instances in which user requests and application requests are handled differently. 
Claim 24 recites, ". . .receiving the application request for manipulation of the selected tile, 
wherein an application originating said application request is associated with the selected 
tile and is an application program other than a tile configuration user interface program, 
and wherein said request includes content. .. manipulating the tile in accordance with the selected 
tile manipulation rule and the content of the request, wherein if the current status is 
determined to be banned, the selected tile manipulation rule includes refusing entry of the 
selected tile in the sidebar and refusing to reveal the selected tile." Claim 30 recites, 
".. .refusing a request originating from an application to insert the selected tile into the 
sidebar, wherein said request from the application is received after removing the selected 
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tile in response to the manipulation request from the user, wherein said application is 
associated with the selected tile and is an application program other than a tile configuration user 
interface program. . . ." Claim 32 recites, ". . .inserting the selected tile in a preferred sidebar 
position in response to receiving a user originated request to insert the selected tile; inserting the 
selected tile in less preferred sidebar position in response to receiving an application 
request to insert the selected tile, wherein an application originating the application request to 
insert the selected tile is associated with the selected tile and is an application program other than 
a tile configuration user interface program. ..." None of the cited references cure this deficiency. 

For at least these reasons, Applicants submit that the cited art fails to teach elements of 
claims 1, 13, 24, 30, and 32 and that these claims are therefore allowable over the cited art. 
Claims 3-9, 11, 12, 14-23, 25-29, 31, and 33 depend from these claims and are allowable for at 
least the same reasons as the independent claims from which they depend. 
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Conclusion 

Applicants submit that the claims are allowable for at least the reasons set forth herein. 
Applicants thus respectfully submit that claims 1, 3-9, and 1 1-33 as presented are in condition 
for allowance and respectfully request favorable reconsideration of this application. 

Although the prior art made of record and not relied upon may be considered pertinent to 
the disclosure, none of these references anticipates or makes obvious the recited aspects of the 
claims. The fact that Applicants may not have specifically traversed any particular assertion by 
the Office should not be construed as indicating Applicants' agreement therewith. 

Applicants wish to expedite prosecution of this application. If the Examiner deems 
the application to not be in condition for allowance, the Examiner is invited and 
encouraged to telephone the undersigned to discuss making an Examiner's amendment to 
place the application in condition for allowance. 

The Commissioner is hereby authorized to charge any deficiency or credit any 
overpayment of any required fee during the entire pendency of this application to Deposit 
Account No. 19-1345. 

Respectfully submitted, 

/Frank R. Agovino/ 

Frank R. Agovino, Reg. No. 27,416 
SENNIGER POWERS LLP 
100 North Broadway, 17th Floor 
St. Louis, Missouri 63102 
(314) 231-5400 

FRA/MAP/lav 
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